Base de données vectorielle

Article Wikipedia : https://en.wikipedia.org/wiki/Vector_database

Exemple de base de données vectorielle :

Journaux liées à cette note :

Première description du gestionnaire de projet de mes rêves #projet-24, #idée, #project-management

Introduction

Cela fait depuis 2022 que je souhaite prototyper un outil de gestion de tâches (issues) avec certaines fonctionnalités que je n'ai trouvées dans aucun outils Open source ou closed-source.

En novembre 2022, j'ai commencé le tout début d'un modèle de données PostgreSQL, mais je n'ai pas continué.

Je souhaite, dans cette note, présenter mon idée de prototype, présenter les fonctionnalités que j'aimerais implémenter.

Nom du projet : Projet 24 - Prototyper le gestionnaire de projet de mes rêves

Ces idées de fonctionnalité sont tirées de besoin personnel que j'ai rencontré depuis 2018, dans mes différents projets professionnel en équipe.

Pour réduire mon temps de rédaction de cette note et la publier au plus tôt, je ne souhaite pas détailler ici l'origine de ces besoins.
Je souhaite juste décrire quelques fonctionnalités que je souhaite et quelque détail technique sans expliquer l'origine de mon besoin.

Sources d'inspiration

Mes principales sources d'inspiration :

Je me projette d'utiliser Projet 24 dans les framework de gestion de projets suivants :

Ainsi qu'avec la technologie sociale Sociocratie 3.0.

Liste de fonctionnalités en vrac

  • Permettre d'importer / exporter une ou plusieurs issues dans un format de fichier YAML.
    • Permettre d'importer / exporter ces fichiers via Git.
    • Permettre l'utilisation de branche : création, suppression, merge de branches.
    • Permettre la gestion des branches via l'interface web.
    • Visualisation web des diff entre deux branches.
    • Permettre de commit ou créer des snapshots d'une branche.
  • Permettre d'attribuer à une issue une estimation basse et haute de temps d'implémentation.
  • Permettre d'activer un Hill Charts sur toute issue.
  • Permettre d'indiquer un niveau d'approximation d'une issue
  • Permettre aux lectures d'une issue d'indiquer leur niveau de compréhension de l'issue
  • Permettre de configurer la taille maximum en mots d'une issue. Pour forcer un certain niveau de synthèse.
  • Permettre de calculer le poids d'une issue en faisant la somme basse et haute de toutes ses dépendances.
  • Système inspiré de Tinder pour prioriser les issues. L'application présente deux issues choisies selon un algorithme Elo et invite l'utilisateur à désigner celle qu'il considère comme prioritaire.
  • Implémenter un système de tags d'issues personnalisés où chaque utilisateur peut créer ses propres étiquettes. La visibilité de ces tags serait configurable : mode privé pour un usage personnel ou mode partagé pour les rendre disponibles aux autres utilisateurs.
  • Permettre de créer des portfolios d'issue par utilisateurs.
  • Pas de séparation des entités Epic (gestion de projet logiciel) / Issue contrairement à ce que fait GitLab.
  • Permettre d'utilisation d'une extension Browser pour enrichir les pages GitHub, GitLab, Linear ou Forgejo avec les fonctionnalités de Projet 24.
  • Permettre au Projet 24 d'améliorer une instance privé Forgejo avec un wrapper HTTP.
  • Système de dashboard pratiquement identique à GitHub projects.
  • Système de commentaire comme GitHub, mais avec un système de thread.
  • Support de wikilink et alias au niveau de toutes les ressources texte.
  • Support d'une fonctionnalité de publication de notes éphémères attachées à chaque utilisateur.
  • Permettre la création d'issues ou de notes "flottantes". Une issue "flottante" n'appartient à aucune ressource spécifique — elle n'est rattachée ni à un projet, ni à un groupe. Cette fonctionnalité me semble essentielle et je compte la détailler dans une note dédiée prochainement.
  • Proposer une extension Browser qui détecte automatiquement les issues liées à l'URL de la page actuelle. Cela permettrait d'accéder rapidement aux issues ou notes "flottantes" selon le contexte de navigation.
  • Très bon support Markdown, contrairement aux implémentations de Slack, Notion ou Linear. Il devrait être possible de basculer entre le mode d'édition riche et le mode markdown. Le contenu copié doit générer du markdown valide dans le presse-papier.
  • Respect strict des conventions Web : permettre l'ouverture de toutes les pages dans un nouvel onglet, etc.
  • Mettre l'accent sur la performance de rendu des pages. Implémenter en priorité un système de métriques pour mesurer les temps de rendu.
  • Proposer un système de génération de titre d'issue et de tag basé sur un LLM.
  • Mettre en place un système qui utilise un LLM pour proposer automatiquement des titres d'issues et des tags.
  • Alimenter une base de données vectorielle avec les descriptions d'issues et leurs commentaires pour activer la recherche sémantique.

Expérience utilisateur

Comme SilverBullet.mb, un outil fait dans un premier temps pour les hackers.

Détails techniques

  • Stockage dans Elasticsearch pour faciliter les recherches par tags et plain text.
  • Utilisation de nanoid de 5 caractères pour identifier les issues.
  • Utilisation de Git hook pre-receive côté serveur pour importer des données (issues, notes, etc)

Aggregator - Backup Numeric Conversation System #backup, #idée

Ce matin, j'ai eu l' #idée et l’envie de créer une appli d'archivage et de centralisation de toutes mes conversations numériques.

L'objectif ? Rassembler en un seul endroit, dans une interface web minimaliste, toutes mes discussions provenant de :

Le support des threads serait utile pour Mattermost et les mails. J'aimerais pouvoir sauvegarder tous ces messages au format brut original et en Markdown. Une fonction pour partager un message ou un thread serait aussi sympa.

Pour la persistance des données, je pense utiliser ElasticSearch avec son moteur vectoriel. Un LLM pourrait assigner automatiquement des tags à chaque conversation. J'aimerais que l'interface web soit minimaliste, orientée vitesse et exploration.

Pour la postérité, toutes ces données devraient être exportées en continu dans un Object Storage, sous un format YAML facilement compréhensible.

Je me demande si ce type d’application existe en Open source ou closed-source 🤔.

Journal du dimanche 15 juin 2025 à 11:02 #vector-database, #JaiDécouvert

En étudiant l'article Wikipedia "Base de données vectorielle", je découvre la liste de différents algorithmes Approximate Nearest Neighbor.

#JaiDécouvert feature extraction algorithms.

These feature vectors may be computed from the raw data using machine learning methods such as feature extraction algorithms, word embeddings or deep learning networks. The goal is that semantically similar data items receive feature vectors close to each other.

source

J'apprends :

In recent benchmarks, HNSW-based implementations have been among the best performers.

source

Je lis :

Databases that use HNSW as search index include:

source

En interrogeant Claude Sonnet 4, j'apprends :

Benchmark indicatif (1M vecteurs 768D) :

Métrique Qdrant pgvector Elasticsearch
Temps indexation 15 min 45 min 25 min
Requête/sec 2000+ 500-800 800-1200
RAM utilisée 4 GB 6 GB 8 GB+
Précision @10 0.95 0.92 0.94
Date création 2021 2021 2022 (support HNSW)
Langage Rust C Java
Open Source Open Source Open Source

Claude Sonnet 4